Dieser Audiobeitrag wird von der Universität Erlangen-Nürnberg präsentiert.

Vielen Dank und hallo von meiner Seite, wie schon gesagt. Gerne Fragen zwischendrin in dem

Vortrag auch, gerne auch auf Englisch. Ich kann auch gerne auf Englisch antworten,

aber mein Ziel ist so ein bisschen authentisch über Scaling-Modelle und meine Erfahrungen zu

reden und es kommt natürlich in der Muttersprache noch oft ein bisschen besser rüber. Deswegen wird

der Vortrag in Englisch sein. Ganz kurz zu mir, ich bin Informatiker, Software-Embwickler im Herzen,

Pragmatiker und Partner bei Senacore. Was das jetzt heißt, was ich da gerade an Attributen

um mich geschmissen habe, sollte hoffentlich im Vortrag so ein bisschen klar werden, was so meine

Ansichten und Ideen zu in dem Fall Scaling Scrum sind. Ein bisschen was übers Unternehmen

werde ich ganz am Schluss auch noch sagen, aber der Fokus soll jetzt erstmal auf den Inhalten liegen.

Scaling Scrum, ja erstmal ein bisschen Basics. Ich weiß oder ich bin mir sicher, dass der

Professor Riele Ihnen da die Grundlagen sehr gut vermittelt hat, aber nochmal so ein bisschen um

die Grundlage zu legen für das, was ich dann über die Scaling Ansätze sagen möchte. Sei es mir

laupt so ein bisschen in die Vergangenheit zu blicken. Ich bin ja auch schon ein bisschen länger dabei,

die Haare sind leicht grau. Wir kommen aus einer Historie in der Software-Entwicklung, die von

Fehlern geprägt ist. Das Bild kennt vielleicht der eine oder die andere, es wird immer wieder gezeigt,

zumindest ich habe es schon hunderte Male gesehen in meinem Leben oder in meiner Berufslaufbahn. Das

ist so die Motivation, warum ein Wasserfall Vorgehen oder auch ein iteratives Vorgehen,

das über längere Zeit läuft, oftmals nicht zu dem erwarteten Ergebnis führt. Also es gibt so

verschiedenste Beteiligte, natürlich erstmal den Kunden, der irgendwas möchte, der das auch erklärt,

aber letztlich, wenn man so ein bisschen rechts unten schaut, auch da schon so die ersten Fehler

macht. Er weiß eigentlich gar nicht, was er wirklich braucht, sondern erklärt einfach, dass er

irgendwas möchte und dann gibt es natürlich so auf dem Weg zur fertigen Software ganz, ganz viele

Missverständnisse, ganz, ganz viele Änderungen auch in den Anforderungen und es führt dann dazu,

dass eben nicht das rauskommt, was man möchte. Letztendlich History of Failures hatte ich gesagt,

wenn man von Failure spricht, muss man sich dann auch überlegen, was ist denn kein Failure,

was ist ein Erfolg. Da gibt es verschiedene Studien, einer der bekanntesten die Agile Survey

von Version One, die wird jedes Jahr neu aufgelegt und macht eine Umfrage unter allen Unternehmen,

die jetzt irgendwie Softwareentwicklungsprojekte machen und da machen wir sehr viele mit weltweit.

Die sagen ja, also wichtig für einen Erfolg ist, man ist in time, man hat das geliefert,

was dem Kunden den größten Nutzen bringt und was ihn dann auch letztendlich irgendwie zufrieden

stellt. Und ja, was sind die Gründe? Da ist jetzt wahrscheinlich auch nichts Neues dabei,

Anforderungen ändern sich im Laufe der Zeit, Menschen, die die Anforderungen stellen,

ändert sich im Laufe der Zeit. Also wenn Sie mal später im Beruf stehen und in so einem Unternehmen

angestellt sind, Software entwickeln, dann werden Sie merken, so die Halbwertszeit von so einem

durchschnittlichen Manager auf einer Position ist jetzt nicht viel mehr als ein halbes Jahr,

weil dann wird er entweder wegbefördert, hochbefördert oder vielleicht sogar zurecht

befördert. Also es ist zumindest ein anderer da, der plötzlich die Anforderungen stellt,

als der, der es vorher gemacht hat. Ja, auch das Verstehen, die Interpretation der Anforderungen

ändert sich und insgesamt ist es halt wirklich extrem schwierig, auf diese Veränderung zu

reagieren, wenn man so einen Wasserfall macht, wenn man so Planungsphasen hat, wenn man dann

Designphasen hat und Umsetzungsphasen hat. Und der letzte Aspekt ist auch noch, dass man,

wenn man nicht das Glück hat in den kleinen Start-up zu arbeiten oder Pech, je nachdem,

wie man das sieht, sondern in so einem größeren Unternehmen, das Software hat, da hat man dann

viele Systeme, die irgendwie miteinander integriert werden müssen, da ist man nie auf der oft so

zitierten grünen Wiese unterwegs, dann muss man integrieren und das ist immer schwierig,

das können Sie nie planen vorher, das wird Sie immer umwerfen, Sie werden immer Überraschungen

überleben, das Erleben, dass Systeme plötzlich anders reagieren, als das spezifiziert ist,

als Sie es gewohnt sind oder als Ihnen der Owner des Systems auch erklärt hat. Und all dieses

führt dazu, dass man sagt, naja, ich muss Agilität reinbringen und das wird Sie jetzt auch nicht